CHAPTER 9
Jingle: Jabber Does Multimedia
To Instant Messaging and Beyond
So far we’ve seen how XMPP can be used to exchange one-to-one messages, participate
in  multi-user  chat  rooms,  and  send  alerts  and  notifications.  But  what  if  text  is  not
enough?  Sometimes  there  is  no  replacement  for  voice,  video,  and  other  rich  media
interactions.
Enter Jingle, defined in [XEP-0166] and a number of related specifications. After several
years of experimentation, in 2005 the XMPP developer community finally got serious
about  adding  support  for  voice  chat,  spurred  on  by  the  launch  of  Google  Talk,  an
XMPP-based service for instant messaging and Voice over Internet Protocol (VoIP). In
fact, the Google Talk team worked with developers in the community to define Jingle
as a refinement of the Google Talk protocol (similar to the way in which XMPP is a
refinement of the original Jabber protocol or Multi-User Chat is a refinement of the
original groupchat protocol).
Jingle Versioning
The  original  protocol  deployed  at  the  Google  Talk  service  has  some
subtle  differences  from  the  protocol  that  has  been  formalized  by  the
XMPP Standards Foundation (with many contributions from members
of the Google Talk team and other developers). You can think of that
original protocol as “Jingle 0.9,” but by the time you read this book, the
version to implement will be “Jingle 1.0,” as published in the relevant
XEPs.
Jingle provides a reliable mechanism for setting up voice calls over the Internet (see
[XEP-0167] for details). Even more interesting, the same basic Jingle methods can be
used  to  negotiate  and  manage  any  kind  of  media  session,  including  video  chat,  file
transfer, and screen sharing. This makes Jingle yet another powerful building block in
the XMPP toolkit.
123
Jingle provides a pluggable model for both application types and transport methods.
Typically, Jingle is used to set up sessions that are not appropriate over XMPP itself.
As we’ve discussed, XMPP is optimized for the exchange of many small snippets of
XML, not data-heavy media streams. The Internet community has defined perfectly
good technologies for the transport of voice, video, files, and other application types.
Jingle therefore simply reuses those technologies for “heavy lifting” rich media sessions.
The basic idea is that Jingle uses XMPP as the signaling channel to set up, manage, and
terminate media sessions, whereas the media data itself is sent either peer-to-peer or
mediated through a dedicated media relay.
Channels and Connections
There are two kinds of channels in Jingle, SIP, and other multimedia
technologies: the signaling channel is used to send messages for overall
session  management,  whereas  the  media  channel  is  used  to  send  the
media data itself. Furthermore, the media channel itself can result in a
connection that is either peer-to-peer (a direct connection between two
clients) or mediated (the data is sent through a relay server).
There are exceptions to this pattern, which we explore in upcoming chapters, but for
now you can think of Jingle as a way to set up media sessions that go outside the normal
XMPP channel. Let’s see how it works.
The Jingle Model
In a Jingle negotiation, one party (the initiator) offers to start a session, and the other
party (the responder) answers the offer by either agreeing to proceed or declining the
invitation. An offer has two parts:
Application type
Transport method
States what is going to be exchanged in the session—for example, voice chat via
the Real-time Transport Protocol (RTP).
Describes how data is going to be sent—for example, using the User Datagram
Protocol (UDP).
The offer triggers a flurry of XMPP traffic between the initiator and the responder, as
their XMPP clients negotiate various parameters related to the application type (e.g.,
audio codecs) and the transport method (e.g., IP addresses and port numbers to check
for connectivity). Once both parties agree on these parameters and the responder sends
a Jingle session-accept message, the session transitions from the pending phase to the
active phase. At this point, the XMPP signaling traffic quiets down as the parties exchange media data (XMPP stanzas can still be exchanged during the active phase as
124 | Chapter 9: Jingle: Jabber Does Multimedia
well, for example, to renegotiate parameters, or to add a new application type such as
video to an existing session). Thus, the overall flow of a Jingle session is as follows:
1. The initiator sends an offer to the responder.
2. The offer consists of one or more application types (voice, video, file transfer, screen
sharing, etc.) and one or more transport methods (UDP, ICE, TCP, etc.).
3. The parties negotiate parameters related to the application type(s) and work to set
up the transport(s).
4. The responder either accepts or declines the offer.
5. If the offer is accepted, the parties exchange data related to the application type(s)
over the negotiated transport method(s).
6. If needed, the parties can modify certain parameters during the life of the session
(e.g., by adding video to a voice chat or switching to a better transport candidate).
7. Eventually, the session ends and the parties go on with their lives.
This flow is illustrated in Figure 9-1.
The following simplified example illustrates the format of an offer using “stubs” for the
application type and transport method:
<iq from="alice@wonderland.lit/rabbithole"
    id="jah28fh1"
    to="sister@realworld.lit/home"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1">
          action="session-initiate"
          initiator="alice@wonderland.lit/rabbithole"
          sid="a73sjjvkla37jfea">
    <content creator="initiator" name="just-an-example">
      <description xmlns="urn:xmpp:jingle:apps:stub:0"/>
      <transport xmlns="urn:xmpp:jingle:transports:stub:0"/>
    </content>
  </jingle>
</iq>
The action attribute specifies the particular request or notification; here a request
to initiate a session.
The sid attribute specifies a unique Session ID for this Jingle session, which is generated by the initiator.
The <description/> element always defines the application type; particular application types are differentiated by the XML namespace of the <description/> element
and, for some application types, by the media attribute (e.g., “audio” or “video”).
The <transport/> element always defines a transport method; particular transport
methods are differentiated by the XML namespace of the <transport/> element.
After the responder acknowledges receipt of the session-initiate and the parties negotiate some parameters related to the application type and the transport method (we
The Jingle Model
| 125
Figure 9-1. Jingle defines a state machine for the flow of a peer-to-peer multimedia session
explore these processes later), the responder would eventually send a session-accept
to the initiator:
<iq from="sister@realworld.lit/home"
    id="b18dh29f"
    to="alice@wonderland.lit/rabbithole"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1"
          action="session-accept"
          initiator="alice@wonderland.lit/rabbithole"
          responder="sister@realworld.lit/home"
          sid="a73sjjvkla37jfea">
    <content creator="initiator" name="just-an-example">
      <description xmlns="urn:xmpp:jingle:apps:stub:0"/>
      <transport xmlns="urn:xmpp:jingle:transports:stub:0"/>
    </content>
  </jingle>
</iq>
126 | Chapter 9: Jingle: Jabber Does Multimedia
The session-accept action is a new IQ-set, not an IQ-result sent in response to the
session-initiate; each Jingle action is a separate IQ-set so that it can be immediately
acknowledged with an IQ-result and thus keep the negotiation moving forward as
fast as possible.
A Jingle action of  session-accept is used to definitively accept the offer. The acceptance usually will include the precise application parameters and transport candidate that is acceptable to the responder.
The  initiator  acknowledges  receipt  of  the  session-accept  (a  simple  IQ-result,  not
shown here) and the parties can exchange “stub” media data over the “stub” transport.
Eventually, one of the parties (here the responder) will terminate the session:
<iq from="sister@realworld.lit/home"
    id="g91hs73n"
    to="alice@wonderland.lit/rabbithole"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1"
          action="session-terminate"
          initiator="alice@wonderland.lit/rabbithole"
          responder="sister@realworld.lit/home"
          sid="a73sjjvkla37jfea">
    <reason>
      <success/>
    </reason>
  </jingle>
</iq>
A Jingle action of session-terminate is used to formally end the session.
The <reason/> element is used to specify why this particular Jingle action is being
sent; it contains a predefined condition and, optionally, a human-readable <text/>
element.
The <success/> element implies that no error has occurred, or that the session has
completed successfully.
The recipient acknowledges receipt of the session-terminate (a simple IQ-result, not
shown here), and the session is ended.
Now that we’ve looked at the overall session flow at a high level using a stub example,
let’s  look  at  how  real  Jingle  sessions  are  established  to  fill  in  the  blanks  for  the
<description/> and <transport/> elements.
Making a Call
Jingle was first developed for one-to-one voice chat over the Internet. In this case, the
application type is a Jingle RTP session, as defined in [XEP-0167] using a datagram
transport method that is appropriate for voice data.
Making a Call
| 127
Transport Types: Datagram and Streaming
There are two basic kinds of transport methods: datagram and streaming. A datagram transport is suitable for applications where some packet
loss is tolerable, such as voice and video (if you lose some packets of
audio or video data, you can interpolate without seriously degrading the
quality). A streaming transport is suitable for applications where packet
loss is not tolerable, such as file transfer (if you lose some packets of file
data, you can’t correctly construct the file). The canonical examples of
datagram and streaming transports are UDP and TCP, respectively.
Here the offered transport method is the simplest one-to-one UDP association, negotiated using the Jingle Raw UDP Transport [XEP-0177]:
<iq from="alice@wonderland.lit/rabbithole"
    id="v73hwcx9"
    to="sister@realworld.lit/home"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1"
          action="session-initiate"
          initiator="alice@wonderland.lit/rabbithole"
          sid="a73sjjvkla37jfea">
    <content creator="initiator" name="voice">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <payload-type id="96" name="speex" clockrate="16000"/>
        <payload-type id="97" name="speex" clockrate="8000"/>
        <payload-type id="0" name="PCMU"/>
        <payload-type id="8" name="PCMA"/>
      </description>
      <transport xmlns="urn:xmpp:jingle:transports:raw-udp:1">
        <candidate candidate="1"
                   generation="0"
                   id="a9j3mnbtu1"
                   ip="10.1.1.104"
                   port="13540"/>
      </transport>
    </content>
  </jingle>
</iq>
For RTP sessions, each <payload-type/> element defines an audio or video codec
and some associated information, such as the clockrate and the number of channels
(e.g., two for stereo).
For many transport methods, each <candidate/> element defines an IP address and
port that can be attempted for direct or mediated communication of media data.
In this case, the initiator’s client wishes to establish an RTP session using any of four
audio codecs in the following preference order:
1. The open source Speex codec at a clockrate of 8,000 Hertz.
128 | Chapter 9: Jingle: Jabber Does Multimedia
2. The open source Speex codec at a clockrate of 16,000 Hertz (this is a “wideband”
codec with higher audio quality).
3. The “PCMU,” or μ-law, flavor of the ITU’s G.719 codec, which is supported in
traditional telephony systems in the U.S. and Japan.
4. The “PCMA,” or a-law, flavor of the ITU’s G.719 codec, which is supported in
telephony systems in the rest of the world.
The initiator’s client also wishes to use the Raw UDP transport, which is defined in
[XEP-0177], with an IP address of 10.1.1.104 and a port of 13540. (We don’t need to
concern  ourselves  here  with  each  and  every  parameter  communicated  in  the  Jingle
stanzas, such as the candidate numbers and IDs or the generation numbers; refer to the
Jingle specifications for all the details.)
Because the response to an XMPP IQ stanza must be either an IQ-result or an IQ-error,
the responder’s client immediately acknowledges receipt (but not yet acceptance) of
the offer:
<iq from="sister@realworld.lit/home"
    id="v73hwcx9"
    to="alice@wonderland.lit/rabbithole"
    type="result"/>
As mentioned, the parties must now negotiate parameters related to the application
type  and  the  transport  method.  In  this  case,  the  responder’s  client  performs  a  few
actions:
• Checks the offered codecs against the list of codecs it supports.
• Optionally sends an informational “ringing” notification to the initiator.
• When it accepts the session, optionally offers an IP address and port number of its
own as another connectivity candidate (e.g., this might be a relay server that the
responder knows about).
The following two examples show the “ringing” notification and the candidate offer:
<iq from="sister@realworld.lit/home"
    id="k3d7abv8"
    to="alice@wonderland.lit/rabbithole"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1"
          action="session-info"
          initiator="alice@wonderland.lit/rabbithole"
          responder="sister@realworld.lit/home"
          sid="a73sjjvkla37jfea">
    <ringing xmlns="urn:xmpp:jingle:apps:rtp:info:1"/>
  </jingle>
</iq>
Here the Jingle action is session-info, which is used to send informational messages
throughout the life of the session.
Making a Call
| 129
This informational message is a simple notification that the other party’s device is
ringing.
And, of course, the responder’s client asks the human user controlling the client if she
wants to accept a voice call from the initiator!
If the responding user wants to talk, the responding client accepts the session by sending
the codecs it supports (here only Speex at a clockrate of 8,000 Hertz) along with an IP
address and port that the responder offers for connectivity checking:
<iq from="sister@realworld.lit/home"
    id="ikw71b54"
    to="alice@wonderland.lit/rabbithole"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1"
          action="session-accept"
          initiator="alice@wonderland.lit/rabbithole"
          responder="sister@realworld.lit/home"
          sid="a73sjjvkla37jfea">
    <content creator="initiator" name="voice">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <payload-type id="97" name="speex" clockrate="8000"/>
      </description>
      <transport xmlns="urn:xmpp:jingle:transports:raw-udp:1">
        <candidate candidate="1"
                   generation="0"
                   id="z7sdjb01hf"
                   ip="208.68.163.214"
                   port="9876"/>
      </transport>
    </content>
  </jingle>
</iq>
The only payload-type that this responder supports (from among those offered by
the initiator) is the open source Speex codec at a clockrate of 8,000 Hertz.
Now the parties can begin to chat over the negotiated voice channel, using the Speex
codec in RTP over a raw UDP connection. Here we leave the world of XMPP behind,
because the media data is sent peer-to-peer or through a media relay, not through the
XMPP servers used by the initiator and responder for call setup. This is the beauty of
Jingle: it uses XMPP for call management but more appropriate transport methods for
voice, video, files, and other binary data.
Eventually, one of the parties will want to end the call. Since this is a call management
action, it is completed over the XMPP signaling channel using a Jingle action of sessionterminate:
<iq from="sister@realworld.lit/home"
    id="ip71v3fz"
    to="alice@wonderland.lit/rabbithole"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1"
130 | Chapter 9: Jingle: Jabber Does Multimedia
          action="session-terminate"
          initiator="alice@wonderland.lit/rabbithole"
          responder="sister@realworld.lit/home"
          sid="a73sjjvkla37jfea">
    <reason><success/></reason>
  </jingle>
</iq>
A Swarm of NATs
That was rather painless, wasn’t it? Well, not so fast! Life on the Internet is never quite
as  easy  as  it  seems.  The  problem  arises  from  that  little  part  about  the  initiator  and
responder exchanging IP addresses where they could be contacted. In today’s world,
you  need  to  be  extremely  careful  about  allowing  connections  to  your  computer  on
random ports. As a result, your computer probably lives behind a firewall to protect
itself from the big, bad Internet. Furthermore, your firewall probably includes something called a Network Address Translator, or NAT. This means that devices inside the
firewall (including your Jabber client) think they have one IP address, whereas devices
outside the network see a different IP address.
As you can see in Figure 9-2, Party 1 thinks his IP address is “1.2.3.4”. However, the
NAT has translated that IP address to “10.0.0.1” for use by outside entities such as
Party 2. If Party 1 tells Party 2 that his IP address is “1.2.3.4” and Party 2 then tries to
contact him at “1.2.3.4” instead of “10.0.0.1”, her communication attempt might fail.
Figure 9-2. Network Address Translators (NATs) make it difficult to establish peer-to-peer media
sessions
Even this description simplifies the problem quite a bit, because there are many different
kinds of NATs. Although we need not worry about all the details here, we do need a
solution to the problem of NAT traversal in order for media to flow reliably. And when
it comes to features like voice chat, reliability matters (if your phone worked only 90%
of the time, you might not use it!).
A Swarm of NATs
| 131
Thankfully, the smart people at the IETF have defined several technologies for NAT
traversal, with catchy names like STUN, TURN, and ICE. XMPP reuses these technologies  so  that  Jingle  clients  can  seamlessly  interact  with  devices  that  implement  the
Session Initiation Protocol (SIP). Here’s a brief overview of these three technologies:
• STUN (“Session Traversal Utilities for NAT”) provides a way for you to find out
what your IP address and port look like from outside your firewall (if, that is, you
are able to contact a STUN server for address lookups).
• TURN (“Traversal Using Relays around NAT”) provides a way for you to relay
media data in case you can’t set up a direct, peer-to-peer connection with the other
party (if, that is, you are able to find a TURN server for media relaying).
• ICE (“Interactive Connectivity Establishment”) provides a consistent way for two
endpoints to rank, communicate, and negotiate all the possible combinations of
direct and mediated connections between them.
These technologies come together in the Jingle ICE-UDP Transport [XEP-0176]. This
transport method results in a lot more XMPP traffic than the Raw UDP method we
looked at in the last section, mainly because there are many more “candidates” (IP
addresses and ports) to be checked. However, the result is greater reliability.
You’ll also notice that STUN and TURN both require additional infrastructure. So far,
Jingle hasn’t even required special XMPP server modules, because the clients have done
all  the  work.  (It  may  seem  that  this  goes  against  the  original  Jabber  philosophy  of
“simple clients, complex servers,” but the story here is that clients really do know best
when it comes to the codecs they support and the exchange of IP+port candidates.)
However, we now need some server-side help, which is provided not by the XMPP
server itself but by specialized STUN servers and TURN relays.
The next section explains the ICE methodology in greater detail.
Jingle on ICE
Interactive Connectivity Establishment is a powerful methodology for figuring out how
to set up media sessions (such as voice and video calls) over the Internet while still
respecting the NATs and firewalls that may exist in a given network. Some NAT traversal methods try to “fake out” firewalls, and therefore are frowned upon by system
administrators, but in contrast, ICE tries to work with NATs.
This “kindler, gentler” approach to NAT traversal requires quite a bit of up-front negotiation between the parties, as they exchange IP+port pairs for UDP.
But  before  the  parties  can  communicate  that  information,  they  need  to  create  their
preferred list of candidates. There are four candidate types (see the ICE specification
for complete details):
132 | Chapter 9: Jingle: Jabber Does Multimedia
Host
Server reflexive
Peer reflexive
This is an IP+port hosted on the device itself (e.g., as obtained via Ethernet, a WiFi hotspot, or a VPN).
This is an IP+port for a party’s device, but translated into a public IP address by a
NAT when the party sends a packet through the NAT to a STUN server or a TURN
server. The party then discovers the server reflexive address for a specific candidate
by contacting the STUN server or TURN server.
A peer reflexive candidate is similar to a server reflexive candidate, except that the
mapping of addresses happens in the NAT when the party sends a STUN binding
request to a peer instead of directly to a STUN or TURN server. The party discovers
the peer reflexive address as a result of connectivity checks later in the negotiation
process.
Relayed
This is the IP+port of a relay server (e.g., as hosted by an ISP). Typically, such a
relay  implements  TURN,  but  it  could  implement  some  other  data-relaying
technology.
Once a Jingle client gathers these candidates, it prioritizes them according to the ICE
rules, and then includes its highest-priority candidates in the session offer it sends to
the responder. The session offer is rather large because it specifies both the payload
types and transport candidates, but for our purposes here, the key aspect of the offer
is the IP address and port of each candidate, along with its priority (candidates with
higher numbers are more highly preferred):
 <iq from="alice@wonderland.lit/rabbithole"
    id="xle82n56"
    to="sister@realworld.lit/home"
    type="set">
  <jingle xmlns="urn:xmpp:jingle:1">
          action="session-initiate"
          initiator="alice@wonderland.lit/rabbithole"
          sid="a73sjjvkla37jfea">
    <content creator="initiator" name="voice">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <payload-type id="96" name="speex" clockrate="16000"/>
        <payload-type id="97" name="speex" clockrate="8000"/>
        <payload-type id="0" name="PCMU"/>
        <payload-type id="8" name="PCMA"/>
      </description>
      <transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"
                 pwd="asd88fgpdd777uzjYhagZg"
                 ufrag="8hhy">
        <candidate component="1"
                   foundation="1"
                   generation="0"
                   ip="10.0.1.1"
                   network="1"
Jingle on ICE | 133
 
                   port="8998"
                   priority="2130706431"
                   protocol="udp"
                   type="host"/>
        <candidate component="1"
                   foundation="2"
                   generation="0"
                   ip="192.0.2.3"
                   network="1"
                   port="45664"
                   priority="1694498815"
                   protocol="udp"
                   rel-addr="10.0.1.1"
                   rel-port="8998"
                   type="srflx"/>
    </content>
  </jingle>
</iq>
 
Don’t worry about how these big numbers are generated! All you need to know is
that a candidate with a larger value for the priority element is preferred in relation
to a candidate with a small value for the priority attribute.
The only protocol supported by ICE is UDP. However, work on an ICE profile for
TCP is ongoing, so the protocol attribute might accept other values in the future.
For server reflexive and peer reflexive candidates, the IP address and port describe
the network address of the party outside the local network the party is on (i.e., as
discovered via STUN). For a relayed candidate, the IP address and port describe the
address of the relay server.
The  rel-addr  and  rel-port  are  used  for  diagnostic  purposes;  they  specify  the  IP
address and port of the host candidate from which the server reflexive, peer reflexive,
or relayed candidate was derived.
When  the  responder  sends  its  session-accept  to  the  initiator,  it  also  sends  a  set  of
possible candidates from its perspective (e.g., it may know about different relay servers).
The parties then send connectivity checks over each pair of possible IP addresses and
ports. More specifically, the responder sends one check from each of its IP+port candidates to each of the IP+port candidates sent by the initiator, and vice versa. This
results in even more traffic between the parties, but this time outside the XMPP channel
because  the  XMPP  channel  uses  TCP,  whereas  ICE  uses  UDP.  (After  the  parties
exchange  their  highest-priority  candidates  in  the  session-initiate  and  sessionaccept messages, they can also send lower-priority candidates using Jingle transportinfo messages.)
For example, the initiator offered the candidates 10.0.1.1:8998 and 192.0.2.3:45664.
If the responder offered the candidates 192.0.2.1:3478 and 10.0.1.2:15999, the parties
would try the following connectivity checks over UDP:
134 | Chapter 9: Jingle: Jabber Does Multimedia
• The  initiator  sends  connectivity  checks  from  10.0.1.1:8998  to  192.0.2.1:3478,
from 10.0.1.1:8998 to 10.0.1.2:15999, from 192.0.2.3:45664 to 192.0.2.1:3478,
and from 192.0.2.3:45664 to 10.0.1.2:15999.
• The responder sends connectivity checks from 192.0.2.1:3478 to 10.0.1.1:8998,
from 192.0.2.1:3478 to 192.0.2.3:45664, from 10.0.1.2:15999 to 10.0.1.1:8998,
and from 10.0.1.2:15999 to 192.0.2.3:45664.
Eventually, these connectivity checks will yield results, because connectivity checks
will reveal the candidate pairs that succeed. And given the large number of candidates
exchanged, the parties are almost guaranteed that at least one of the candidates pairs
will succeed, thus leading to reliable call setup.
Additional Jingle Actions
So  far,  we’ve  looked  at  the  core  Jingle  actions:  session-initiate,  session-accept,
session-info, transport-info, and session-terminate. However, several other Jingle
actions enable you to modify a session while it is in progress:
content-add
content-remove
content-modify
description-info
transport-replace
The content-add action enables you to add an entire content-type to a session (e.g.,
to add video to a voice call); this action is accepted or rejected using the contentaccept action or the content-reject action.
The  content-remove  action  enables  you  to  delete  an  entire  content-type  from  a
session  (e.g.,  to  remove  video  from  a  combined  voice-and-video  session);  the
content-replace action is silently accepted.
The  rarely  used  content-modify  action  changes  the  directionality  of  media  exchange (from sender-only to both, receiver-only to both, etc.).
The description-info action enables you to send hints about application parameters within a session (e.g., to provide suggestions about the height and width of
a video feed).
The transport-replace action enables you to redefine a transport method while it
is in use (e.g., to change an IP address or port); this action is accepted or rejected
using the transport-accept action or the transport-reject action.
We show how some of these are used in Chapter 10.
Additional Jingle Actions
| 135
Summary
Jingle is a relatively recent addition to the XMPP toolkit. Although it provides a flexible
framework for the negotiation and management of peer-to-peer media sessions, to date
it has mostly been used for one-to-one voice chat. At the time of this writing, the Google
Talk  service  and  several  open  source  XMPP  clients  have  also  added  video  support.
Moreover, the same basic session-management pattern can be applied to many different
kinds  of  negotiation  (for  example,  Chapter  10  explains  how  to  use  Jingle  for  file
transfer).
You probably noticed that Jingle uses IQ stanzas between two parties in order to negotiate a one-to-one session. But what if you want to set up a multi-party session, such
as a conference call? In fact, a number of Jingle developers are exploring the potential
of sending Jingle signaling through the Multi-User Chat (MUC) rooms we discussed
in Chapter 7, resulting in a hybrid of Jingle and MUC. You’ll need to check out http://
xmpp.org for all the details, because they are being defined as we go to press.
The potential of Jingle is just starting to be explored, and the next few years promise
to bring new Jingle applications for features, such as torrents, screen sharing, and virtual
private networks (VPNs).
136 | Chapter 9: Jingle: Jabber Does Multimedia
